Semiconductor companies developing standard products usually end up developing families of integrated circuits (IC) to address a specific market or closely connected markets. Individual members among the family of devices are often substantially similar with certain specific modifications. The variations within the family presents a challenge for the engineering teams developing the products. The engineering teams need to develop several devices in parallel yet ensure that design modifications affecting the common aspects of the devices are implemented in all devices in the product family.
Companies that develop application specific integrated circuits (ASICs) also face a similar problem. With ASIC devices, the problem manifests itself not at the device level but at the macro level. The common elements are often analog macros such as digital to analog converters (DACs), phase locked loops (PLLs) or even standard cell logic gates. As such, the “family” of products is a “family” of macros. Since a close relationship still exists between the various designs, changes in common aspects of the designs need to be implemented in all members of the product family. Two specific challenges are presented to the IC design team, (i) tracking the similarity between devices in the product family and (ii) ensuring changes to the common aspects of the product family are implemented in all products
If the devices in the product family are developed either by separate teams or groups, or the developments are performed sequentially in time, keeping track of all the various changes that need to be implemented in several devices becomes either a communication challenge and/or a schedule issue. In essence, the problem is one of managing the content and complexity of the design databases for several closely related IC developments. Support within appropriate electronic design automation (EDA) software used to design the ICs is also important.
An industry practice is at best to recognize the problem as an issue. Typically, each development team depends on a particular individual, usually the team manager, to track common aspects of devices in a product family or devices or macros. The particular individual approach is an ad-hoc process for controlling the development challenge. The individual needs to be aware of all the concurrent developments, making the person less efficient as an IC designer since more time is spent in meetings and less time designing. Therefore, the process is both inefficient and does not capture the design information in a controlled way. If the particular individual is no longer part of the team, information is lost and the tracking mechanism fails. Development will continue but productivity falls since work is repeated on several related devices when the work could have been performed just once.
Referring to FIG. 1, a flow diagram of a conventional method for developing a device is shown. The method begins when a plan to create a new macro or device layout is identified (i.e., block 20). If no similar existing design is available (i.e., the NO branch of decision block 22), a new layout database is generated from scratch (i.e., block 24). If a similar design already exists (i.e., the YES branch of decision block 22), a copy of the existing database may be modified to achieve the planned design (i.e., block 26).
An initial layout of the derivative product is then generated from the new or modified database (i.e., block 28). The initial layout is subjected to manual review (i.e., block 30) and physical verification (i.e., block 32). After any detected errors are corrected, the layout is ready to release (i.e., block 34). A copy of the layout database is archived for future use (i.e., block 36) and a Graphic Design System II (GDSII) layout file is streamed out for release to a foundry (i.e., block 38).
Conventional development of a derivative product in existing design flows used in industry practice can, but does not always, feed the changes made to the existing product back into the database for the baseline product. Further derivative products follow an iterative process and thus each subsequent product has an increasing number of baselines available to choose from as a starting point. A set of complex, related layout databases is thus formed. However, the relationships between each product are not captured in a rigorous fashion.